Creature Corp - Movie Game Contest Entry

[iWasAdam]

no problem
Here is the complete mx2 V1.105 source. This is the base I am using.
https://github.com/blitz-research/monkey2/releases/tag/v1.0.5

[iWasAdam]

Back to Creature corp.

I had a quick look at the source and found a few things that could be done to make things much simpler.

The (lets just call them all) men graphics seem to be approx 50x100
we can therefore split and simplify them into the following:
hair 50x50 probably 4 styles more can be added later with hats! - grey base
face/hands 50x100 4 kinds - grey base
legs 50x100 1kind - grey base only used when skirts or shorts are being worn

split the body into 2: top and bottom
tops 50x50 4 kinds - grey base
skirt 50x50 - grey base
trousers 50x50 - grey base
long skirt/dress 50x50 - grey base
shoes 50x50 4 kinds? grey base

using these as the base graphics we can construct any person of any race with any color of clothes

it would also mean we could let the user create their own character too...

the women and men share the same face types and hair styles - it's only really the tops that would feature breasts

Your thoughts?

[Derron]

They have different faces (not just morphs)...but this only adds another variation, no prob.
Customers could wear hats/basecaps...

I thought about setting up such a thing too...but didn't want to create another big subproject.

For rendering this means that certain areas of the skin/clothes get modified to only receive shadows but do not have color (diffuse/specular...). That way hair can still throw a shadow on clothes...as long as there is no odd shape in the clothing (spikes, or something else needing custom thrown shadows).
As I am now a master *cough cough* in python scripting i could try if I can automate that stuff. An external tool would then trim the stuff into the spritesheets (but storing needed offsets... So you do not need to take care of such stuff)
You could even split of the shadow on the ground. That way you can get rid of a lot of "semitransparent areas" in the spritesheets.


For a face-gen in tvtower I used this layerstyle approach to allow various skintones etc. It is worth the hassle if you intend to have dozens of customers, employees etc.


Similar stuff could be done for shelves/desks/ .. have specific places at which items can get placed. Some get an old phone and booms, others a box of pencils... Just to add variation here and there. For everything you render 4 directions, so you could rotate stuff randomly (of course talking about pencils and books.. the phone needs to face seat position).

If there is some interest I could try to collect together the various 3d models (referenced them from various folders...not nice for easy uploads. For computer stores I have some other models done...low poly "xerox style" copy machine, power plugs, tools like wrangler/hammer/... There is a lot one could reuse/modify for a lot of purposes.
Think I also have the inner of a TV (condensators etc) done...fewer stuff to create :-)


Bye
Ron

[Derron]

Reorganized my blender-python-scripts to contain some functions instead of "procedural code". This eases reusage (doing item and character renders in the same script), eases "portability" in case of blender API upgrades (only update one location instead of dozens) - and most important: helps learning Python a bit.

While doing this I asked myself how to properly do the selfshadowing on "invisible parts" (so rendering the clothes shadows thrown on the hands, (also invisible) throusers,..). With shadow catchers this should work - so temporarily assign a shadow catcher material to the other parts. BUT ... I am not sure if the shadows are then also casted to the ground. So a shirt might cast its shadow to the ground then, the throusers too - but the whole body in the othe rendersteps then too. I assume shadow catchers take care of this already.

While posting this I just thought: Blender is such a kind of "Rapid Prototyping Renderer" it will take not much time to setup a testcase - and voila, fired it up in 3 seconds, added a plane and a cube, set them to shadowcatchers and made the default lamp a sun - it took literally less time than writing this paragraph.


Seems to work as planned.


So next thing is to extend the adjusted script to backup/restore material settings - or in this case some more object options than now. Once this is working I need to find out how to access "custom properties" of objects. Why? I could either name objects/groups in a special way to describe them as "top clothing" (shirt, tie, ...), "bottom clothing" (throusers, skirt), "shoes", hair and body - or I could assign some kind of "custom property" for it (type = "body", type = "clothing_top" ...). In the script I would then "shadow catch"ify all objects not belonging to a desired type.

I am not sure how to tackle the head of the chars now - as they are attached to the body and no separate "object" - so Blender's own "shadow catcher" wont work. I either need to hide "vertex groups" then (head is then an own vertex group, same for body) - with the shadow catcher then only rendering the "corpse/body" (think with a nearly top down shadow the head influences not that much), or I needed to separate the shadow on a custom shadow-layer-render (so body is only having selfshadows but no "ground shadow").
Think that portion will be the biggest hassle - rest seems pretty easy to do if the API exposes all the needed stuff.

Aside of that: I think we could create whole body+head bases in various skin tones - so this allows the eye (pupil) color can stay correct -albeit in this rendersize you do not see it properly. I thought of rendering it in "grey" as this allows easy colorization ingame (means you define some skin tones in the game and it does the colorization on startup, aka "create on the fly"). If that is too much for now I would suggest to render them out in some basic skin tones (Caucasian, African, Asian) and during rendering give them slight variations via "setColor" .This modifies eye color too, but if done on a very small percentage it should work - and give each one a slight individual tone (a bit more yellowish, a bit darker ...).

If we really needed to render "head" on its own (for more variation) we should consider rendering "eyes" + "extras" in an own step - so glasses + eyes + facial hair are extra thingies - as long as basic head shape stays "very similar" it could work. But for glasses you eg. need to take care to render it with the "smallest possible nose" (so to cover the least minimum possible. A bit "too much" for such a thing. So as said the best thing might be to prepare some "base bodies" (1-X* Caucasian/Asian/African - for male and female each).
If we now also talkes about body height, this already increases sprite count by another factor (as this needs custom cloth-renders too).



@ Qube
You brought in the idea of the computer shop: so elaborate a bit on your ideas to check if they suit a "longer game" or just a casual 5-minutes-a-session style game.


bye
Ron

[Qube]

@ Qube
You brought in the idea of the computer shop: so elaborate a bit on your ideas to check if they suit a "longer game" or just a casual 5-minutes-a-session style game.

My idea I've pondered on / off for a long time would be designed for a long play but could be dipped into for 5 minutes if you wanted.

It would have :

Stock management.
Staff ( sales / technical ).
Sell, build and repair PC's.
Customers & reputation system.
Money management.

The quality of staff depends on the amount of hourly wage they are paid. For example a cheap technical dude could have up to a 50% failure rate on builds / repairs. The customer would then bring back the PC which effects the reputation of your business and thus leading to less customers coming to your shop. Less customers = less income and as you still have to pay all the bills each month you risk going bankrupt.

Similar with sales people. The cheaper staff loose up to 50% of customer sales and the rest is the same as above.

Stock management - based on requests of customers and trends which change. You have to order in the right amount of goods and be careful not to over stock on expensive items which loose popularity and become unsaleable.

Money management - making sure you've invested in enough stock, can pay all the staffs wages ( or they go on strike ) and pay the bills.

Also there would be things like building a PC. For that you would have a build list of parts and you would have to make sure you select the right bits from the stock. A customer could bring a PC in with a virus, corrupt OS etc and you would need to select the right piece of diagnostic kit, allocate the staff member with the right skill set etc.

As the business grows you would then buy more floors in the building expanding your business.

That's a very rough outline but I hope you get the idea

[Derron]

This sounds similar to what I thought (of course I assumed "computer sale" not "computer repair" but this is just a "theme").

What I am not sure about is, how you handle "motivation" in a long play. So what would you add "peux a peux" during the game (read "unlocking features"). Is it just "growing bigger and bigger"?


@ repair
New technics need new tools ... - this would even allow "research" to speed up repair stuff. So this part is something you could create "simple" at the begin and extend later on.


@ stock management
Think this is - together with "diagnostic tools" in repair - the portion allowing the best extensions. You could make things (if desired) more complex by adding contracts (supply for 3 years) or inventions/trends/ ... as you suggested. So Yay, Win98 licences on sale!!



What do you think about "customers" being treated similar to customers in Theme Park (and the likes) - so some kind of "satisfaction" level ("will come back") - so your company has some kind of "satisfaction level" which inflicts the amount of customers coming to your shop (this also adds the keyword: advertising!).



@ engine
How do you (and IWasAdam) think about coding the grid engine, gui stuff etc? I am pretty sure that you are capable of creating better performing stuff than my "extendable" and surely "overly complex" (aka "more than needed") approach to a tile engine. I have GUI stuff and way more done already - in my DIG framework, but you are then limited to BlitzMax (NG) and so no html5 or whatever is possible with other languages (m2, AGK). But yes, if you know my framework (and all its culprits :p) you could achieve some stuff rather quick - but it can be a bit overwhelming. I personally like to do stuff with BMX-NG as I'd like to "support" NG that way (finding bugs, showing of that "it works" and so on).

As said I do not see problems in more or less doing "idea discussing", "code extension" and GFX if someone else wants to try to be "the coder".

@ engine 2
Benefit is: once you created such a kind of simulation game, you could reuse sooo much stuff (code wise) for other simulation games (like my initial idea of "creation corp").


I also wonder if it's only us 3 interested in such a thing, or if there are others around waiting for their moment to speak up.

bye
Ron

[Qube]

What I am not sure about is, how you handle "motivation" in a long play. So what would you add "peux a peux" during the game (read "unlocking features"). Is it just "growing bigger and bigger"?

My idea for the long term play was to be able to buy better equipment / software for the company. Like in Theme Park, every ride is not available from the get go. Similarly, I would extend that side on staffing, hardware, software etc. So there is a goal to aim for on what you can buy in.

What do you think about "customers" being treated similar to customers in Theme Park (and the likes) - so some kind of "satisfaction" level ("will come back") - so your company has some kind of "satisfaction level" which inflicts the amount of customers coming to your shop (this also adds the keyword: advertising!).

That was my basic idea as referenced in my post. Sales / Tech staff satisfaction based on their quality. If you hire cheap staff ( as you would more likely have to in the beginning ) then there is a percentage success rate to that staff member which effects customer satisfaction, which in turn leads to shop reputation and customer foot fall.

@ engine

For commercial purposes I would personally use AGK2 so I could target all desktop and mobile in one go. I'd also use it's 3D engine in orthogonal view, all filtering turned off and the camera setup to give it that super crisp pixel look. That way all the Z sorting is handled for you and no need to go for a software based orthogonal system as you can achieve the exact same result in 3D and no filtering.

The characters would all share a common generic male / female shape as I doubt it's worth creating multiple male / female shapes and really not worth the effort. You could split them up into torso, legs, shoes, arms, head, hair. That would open up to have heaps of character varieties without having to model / animate each individual.

Of course this type of game would be GUI heavy but it's not hard to write a GUI system, it's just boring.

Benefit is: once you created such a kind of simulation game, you could reuse sooo much stuff (code wise) for other simulation games (like my initial idea of "creation corp").

The GUI and the orthogonal code could be reused over and over again, especially the GUI code. So time spent creating that is not a waste at all.

I also wonder if it's only us 3 interested in such a thing, or if there are others around waiting for their moment to speak up.

I think such a game has a good chance of catching on. If you take your Creature Corp as an example + how many of us were interested in what it's all about it just goes to show that a game in that kinda environment appears to have appeal.

[Qube]

Addon :

What you presented for the game comp was a raw idea. The fact that it gained a lot of interest is a very good thing. The style and immediate interest was spot on. The GUI side did look a bit old linux-esque but that is nit picking and something that could be fixed.

I think the raw nutshell of what you have works really well. I know it's highly unfinished and there is a tonne load to do but what you have right now is a great focal point to creating a top notch sim.

[iWasAdam]

@Qube do you know if agk supports monkey2 language concepts - oop, lambdas, etc?

[Qube]

@Qube do you know if agk supports monkey2 language concepts - oop, lambdas, etc?

He he! AGK is old school procedural programming and there is no OOP or swishy language features. Best you can get is defining types for this.x, this.y etc. I like it though because it just works out the box with no messing around + it's very easy to learn

[Derron]

@ Adam
For the Monkey2-things I would like you to open up a new thread - and if you like, also post a "sample" there, which utilizes your framework so we can see if that compiles with "monkey2 1.0.5"

within "monkey2-1.0.5":
(assuming you have done a "sudo apt-get install build-essential" before)
$ chmod +x scripts/*.sh
$ chmod +x bin/mx2cc_linux
$ cd scripts
$ ./rebuildall.sh
...waiting for the modules to get compiled
Afterwards there was a bin/ted2_linux/ted2 binary which enabled starting to code.


@ Qube
So I assume the whole thing is more or less a single file project (with "includes" rather than "imports") with all "objects" seeing each other? I think it is a bit of a pity that AGK does not over "lite OOP" like BlitzMax. Am not sure how complicate/troublesome/tricky bigger projects get without proper encapsulation. Regarding GUI: I am not talking about simple buttons. My GUI has accordeons,  dropdown/comboboxes, customizable tooltips, modal widgets, textareas, sliders, lists, versatile scrollbars, drag'n'drop, layers/limits, event system ... and uses nine patches, content padding, bitmap fonts (also talking about text wrapping, text-formatting support), ... Things can get pretty "complex" (or at least "heavy") once you need more and more features and widget kinds. But yes, Buttons, checkboxes, simple "state machines" (radio buttons, ...) are done pretty quick. Handling modal dialogues etc. can be done procedurally ("if gameMenuIsShown then...") but it would be nice if it was done at least semi-automatically.
If there is no much GUI/HUD-stuff to do then one could do it that way, but the more options you provide to the player, the more you benefit from "automatization".

But even if that is not of interest for you: some things from my Dig framework might be of use - not code wise but "approach wise". Some might of course be useless, as already "natively" provided by AGK - or other frameworks (playniax?).
And yes, I understand that "more platforms" is a good argument. If monkey(1)/cerberus wasn't case sensitive and had a blitzmax-like module system, I would suggest this one to allow html5/mobile development. 


@ game
So gameplay would be single player or would you plan to have kind of "cities" consisting of multiple stores fighting for a limited amount of customers, stock supply ...? So no need to render the other stores - just synchronizing "numbers" and people "moods".


bye
Ron

[iWasAdam]

@ Derron - what version of Linux are you using 

[iWasAdam]

I would hold off doing render for the moment. The reason I say this is:
Get the base game concept and operation sorted - the graphical output can cloud things - it's easy/hard to get that right and can lead to burnout, which means the gameplay suffers.

In essence first think gameplay with (say even ascii graphics) D=desk, @=person #=wall
I know it sound dumb, but the base roguelike systems would work well for this and allow you to focus on all the nasty stuff...

[Steve Elliott]

@Qube do you know if agk supports monkey2 language concepts - oop, lambdas, etc?

Joe Armstrong, the creator of Erlang:

The problem with object-oriented languages is they've got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle.

Obviously talking about inheritance 

[Derron]

Code Select Expand


$ inxi -b
System:    Host: RonnyPC Kernel: 4.10.0-38-generic x86_64 (64 bit) Desktop: Xfce 4.12.3
           Distro: Linux Mint 18.3 Sylvia
Machine:   Mobo: ASUSTeK model: F1A75-M LE v: Rev X.0x Bios: American Megatrends v: 1505 date: 08/07/2012
CPU:       Quad core AMD A8-3850 APU with Radeon HD Graphics (-MCP-) speed/max: 1100/2900 MHz
Graphics:  Card: NVIDIA GK106 [GeForce GTX 650 Ti Boost]
           Display Server: X.Org 1.18.4 drivers: nvidia (unloaded: fbdev,vesa,nouveau)
           Resolution: 1920x1200@59.95hz, 1280x1024@60.02hz
           GLX Renderer: GeForce GTX 650 Ti BOOST/PCIe/SSE2 GLX Version: 4.5.0 NVIDIA 384.111



@ graphics
For now I do not code the game - as it still might "diverge" into something each of us will do on its own - and I still want to learn a bit on rendering such game sprites (as I would use that for a 2D-front-view of TVTower too - somewhen in a dozen years ;-)).
So while my script evolves (iterating through group elements, setting options of objects - like "is shadow catcher" ...) I also learned how to do better "linked duplicate" objects (so mesh data, modifiers, ... are referenced rather hard copies) but at the same time modify materials on that duplicates (in essence: change from "material - data" links to "material - object"). This reduces file size of "all characters" with compressed 35 MB to way less (still not finished cleaning up stuff).

So it is not just coding a game - it is always "learning something".

Also do not forget: it is not creating graphics, but the "possibility" to do so. I do not render out specific views nor do I create animations. I just prepare stuff to automate rendering setups. Think of the next competition needing 20 random monsters  ... create some basics, set the camera, run the script and I get animation sprites for all desired movement directions.


bye
Ron