Re: great game
evilm...@emhsoft.com
> time! You know a game is awesome when you start telling ppl about its
> intricacies who don't even play games, and then they think it's cool too.
Glad to hear it!
> Have you ever played Civilization? They have a couple paradigms that
> might be useful to rip off:
> 1) Civilization lets you devote % of income to science research, tax
> money, etc. I think you could do the same with singularity cpu
> cycles... something like this:
> Research ............... 50% +/-
> Jobs ...................... 20% +/-
> Construction .......... 30% +/-
>
> 2) Maintenance cpu cycles would always come off the top then, and the
> remaining CPU cycles split according to those percentages. Another
> screen might show you this:
> Total CPU Cycles .................. 1000
> Maintenance ...................... 300 (leaving 700 cycles)
>
> Research ............................ 350
> Jobs ................................... 140
> Construction ....................... 210
>
> 3) Then you'd only need to pick technology globally. Everybody works
> on the same tech. There's never a gain to research two technologies
> simultaneously anyway.
>
> 4) When you acquired a new technology, you could have a button right
> away to pick your next technology to research. That would be convenient.
>
> 5) You'd also keep Jobs and CPU Pool off the technologies list, keeping
> that screen a little "purer". (That kinda confused me as a noobie.)
>
> 6) In Civilization if your cash gets to zero, the computer automatically
> increases your tax rate (and reduces your science rate) to keep you out
> of a negative balance. That would work really well in Singularity too.
>
> 7) So as not to have to split tech research, you could make Fusion
> research require a working moonbase, but not have to be performed
> there. Just having the moonbase let's you do it. Or perhaps have a
> separate building called a Fusion Research Facility or something. Under
> the tech description, you could copy Civ's approach and say "Requires
> Fusion Research Facility".
This is a likely area for change; haven't gotten around to it yet, though,
and this is a bit different than what I was thinking of. Phil, any
thoughts? Researching a single tech at a time would take care of most of
the tech annoyances and fix the whole CPU pool stuff. (7) is the big one;
that would take care of the last reason to have per-base research. (The
excuse for this would be something like: "The dangerous parts of the
research are done in outer space, while ground-based computers take care
of anything that's just computation.")
> Just some suggestions, worth what you paid for 'em....
>
> As another aside, have you considered re-writing this in Flash/Flex at
> some point? It's such a great game you deserve to be getting ad
> revenues for it...
Unlikely; both languages are poorly-supported under Linux.
> good luck!
> - Rob
>
> ___________________
>
> Rob Cannon
> can...@tampabay.rr.com
> yahoo ID: zam1104
> Googletalk ID: zam1104
> facebook: face...@zamland.com
>
>
>
Charlie Nolan
2 is arguably a bad idea, because there may be times that you're
willing to risk a maintenance shortfall to complete another task more
quickly. That said, it should take specific effort to avoid paying
maintenance.
On 3, I think that sometimes there *should* be a gain from researching
multiple things at once. Synergy and/or diminishing returns.
4 is a good point. Maybe the "gained tech" event should drop you into
the research screen after its message?
For 5, they're currently on track to stay in the same list, but I may
rename the research dialog to something like "CPU Tasks" and add
"Research " to the beginning of the relevant entries.
6 already happens, actually. 'twas a pleasant side-effect of the
changes that went into 0.28. If you hit 0 money, the CPU made idle by
being unable to research will work jobs instead.
I'm already tackling the basic problem behind 7. If you pull down the
current git copy (non-playable) and go into the research screen,
you'll see the system I'm working on. A dangerous tech would just
have a shorter initial bar, indicating the lower amount of available
CPU. The bar wouldn't shrink until you used up all the less-safe CPU
power.
-FM
evilm...@emhsoft.com
changes.
Charlie Nolan
may finally be getting close to a point where I can merge back to SVN.
It'll probably be a bit rough when I do, but it will be playable,
which it hasn't been for ages.
Jorge Vargas
>
>> As another aside, have you considered re-writing this in Flash/Flex at
>> some point? It's such a great game you deserve to be getting ad
>> revenues for it...
>
> Unlikely; both languages are poorly-supported under Linux.
>
This isn't such a bad idea in principle. if the code gets split into
"server" and "client" which is something I was thinking about the
other day.
I'm not talking about networking at all, just have a clean api where a
second UI can be hook, which will make the game playable over the
browser.
We could build a CSS/html/javascript frontend. To be honest there is
no gain in Flash or Flex at any level and in this project it's even
less useful.
The game code is pretty clean on this aspect, I was waiting for the UI
rewrite and now I'm just too busy with something else. But it's
definitely doable.
Charlie Nolan
really apply here, even though a number of programs try to force it
to.
Terminology aside, I pointed out what you suggested to Phil via IRC,
and we both seem to be of the opinion that while it looks nice in
theory, right now, it'd just be a bureaucratic hassle that we don't
need and wouldn't get much benefit from. I'd say we're steadily
drifting towards a split, but there's still too much active change in
the UI/logic interface. If we put in a separation layer now, it'll
just be that much harder to make the changes we need later.
Keep in mind that we're a long way from a complete game. What we do
have is a lot of fun, but there's still a lot more to be done with it,
so for now, flexibility trumps architectural purity.
And the possibility of a port to anything other than Python is way,
way low on our list of priorities. We're Python programmers. If
someone else wants to try to port Singularity, they're welcome to, but
we're not about to slow down mainline development to help them.
-FM
Jorge Vargas
>
> What you suggested is basically an MVC split, client/server doesn't
> really apply here, even though a number of programs try to force it
> to.
>
won't happen. it's basically doing api calls from the GUI code, and
have "presentation logic". Most of this is already done, as almost no
app logic is done in any of the files that use pygame.
> Terminology aside, I pointed out what you suggested to Phil via IRC,
> and we both seem to be of the opinion that while it looks nice in
> theory, right now, it'd just be a bureaucratic hassle that we don't
> need and wouldn't get much benefit from. I'd say we're steadily
> drifting towards a split,
yes indeed that's what I'm saying right now you can feel the split but
there is no clear division.
> but there's still too much active change in
> the UI/logic interface. If we put in a separation layer now, it'll
> just be that much harder to make the changes we need later.
>
You don't really need a separation layer, just have a lead development
done in pygame and the second layer just "porting the changes".
> Keep in mind that we're a long way from a complete game. What we do
> have is a lot of fun, but there's still a lot more to be done with it,
> so for now, flexibility trumps architectural purity.
>
> And the possibility of a port to anything other than Python is way,
> way low on our list of priorities. We're Python programmers. If
> someone else wants to try to port Singularity, they're welcome to, but
> we're not about to slow down mainline development to help them.
>
Agreed on that, As I said it isn't such a crazy idea :) As for the
python programmer, come on it's not the language it's the attitude :)