(2018/04/11: Edited thread title from "Compo: undisclosed game" to "Creature Corp - Movie Game Contest Entry", also added the logo to the start of the thread)
(https://abload.de/img/logoqfp8h.png)
Some weeks ago I planned a game and started creating a grid map system on that weekend in february
(https://i.imgur.com/AhmMpy9.gif)
Since then I did not have much time - just a few evenings on another weekend to introduce basic tile-object interaction (do not want to disclose too much yet).
While my weekends were pretty much stuffed with buddy/family time I got some time since monday and fiddled a bit with problems I needed to tackle.
So I plan to have items being spread across more than one single grid/tile. For this I added "dummy tiles" which just redirect their stuff to the parent but am there so the underlaying tile system does not need to know about differences - it just sees "there is a tile and I know how to handle this stuff".
Ok, but then I came across what most iso-tilemap-developers will come across somewhen during development: painting order.
For single-tile approaches this is not thaaat hard: sort by some kind of "x + y + zHeight"-fake-ZDepth (so the more bottom right an item starts, the later it will get rendered. But I wanted to have multi-tile objects. How to tackle them? No problem if you have your images/sprites split correctly already. But this can get pretty tedious if you have to do this over and over.
Welcome to automation land.
So the last days I wrote some kind of "tile extractor" which extracts "subtiles/cells" from a sprite. Give it an image and describe the amount of cols/rows defined there.
The system then creates some polygons (according to some rules on how to "cut"), uses these polygons as shape and cuts individual segments out of the base image. Then it tries to merge single segments together if needed (eg. you have a not-all-tiles-using object with some graphical overhang). Means when using the above "fake z-depth"-approach it will work again with less problems (else you will see multi-tile-objects overlapping other items which they shouldn't).
Afterwards the single images are put into a spriteatlas and some sprites are created for convenient access.
(https://www.syntaxbomb.com/proxy.php?request=http%3A%2F%2Fi.imgur.com%2FLOu7rxX.png&hash=f1ac993eea338baddda8af0ae5edb209c7f5ce5a)
As you see I have to fight some problems with corrupted memory - surely some pixmap offsets are incorrect - had trouble with "PixmapWindow" these days ;-)
bye
Ron
ooh. sounds complex :P
But I really like the choice of colors and the subtle shading - still looks very nice though :)
It was about this time that I gave up on isometric in 2d and moved everything into 3d for this sort of thing. The clipping and sorting is all automatic and you don't have to think about it.
..you guys really cooking something nice..i really like this..is this a game or tool to make a game ?
Engine for the compo entry game.
Engine code will be added to my FOSS blitzmax framework Dig.
@ subtle colors
The final images will be in all glory colors ;-).
Yeah the 2d part makes it hard. Think with a static camera (orientation wise) one could even use 3 objects aligned to the camera...similar to hundreds of parallax layers.
While 3d has plenty of benefits I am not sure about performance once you do some detailled models. Animations and the likes are of course more cool..as dynamically addable instead of using prerendered images.
Bye
Ron
This looks interesting, keep us posted.
Nice to see you create something else than "tv tower", keep trying ! :)
I like the look of how ron's game is going. Should be some interesting entries to look at by deadline day.
Oo, nice looking iso game ;D - Look forward to seeing it.
Wow, that certainly looks interesting..
in my mind i simplify it to a top down 2D map. Then the map is a maze, with balls placed by the user, and an auto pathfinder from A to B.
but I don't see what the game is.
Quote from: meems on March 16, 2018, 18:06:52
in my mind i simplify it to a top down 2D map. Then the map is a maze, with balls placed by the user, and an auto pathfinder from A to B.
but I don't see what the game is.
It's not the game. That's a demo of the game engine.
Thanks Xerra ...you were faster with your reply.
I do not want to expose much of the game "idea", which is why I only posted the technical stuff. The isometric display is just my choice to represent some visual stuff which would not be needed for the game - could do everything with lists, selected items and some buttons + tooltips.
But I want to use such compos to create something "new" in regards to not having done such a thing before - might be "player profiles" and "casual games" like in the autumn compo, or here: something with an isometric grid.
bye
Ron
Finally found some time do tinker with the project:
Friday evening I created a simple character and played a bit with animations in Blender
(https://www.syntaxbomb.com/proxy.php?request=http%3A%2F%2Fi.imgur.com%2FAig4sJe.png&hash=fbfc62c7680a9689bd349fbfe6c145ee43e69bc1)
Saturday was family time so only tinkered a bit on how to render tiles with shadows but "tileable". Was not able to come up with a proper solution. Materials have this slight gradients on them - not much, but putting them next to each other makes them pretty hard visible.
(https://www.syntaxbomb.com/proxy.php?request=http%3A%2F%2Fi.imgur.com%2FOg36xpE.png&hash=3062c23309549c22fa5e1a2d591c5515ff3514ae)
I thought of using an "emission"-hack. Means setting the material of the walls to be emissive. I would get rid of the shadows but especially in corners you would not have shadows as well and this looks pretty odd.
Think I will have to fire up my painting programme at the end and manually make them "tileable".
Only other noteworthy result for that day was a simple spriteatlas-generator (takes directory's images and puts them onto a spriteatlas + exporting an XML file readable by my Dig-frameworks registry.spriteloader-class). It does trimming but Cycles renderer left some "fireflies" on the images, so there are pixels with 1/255th alpha stopping the auto-trim - could add a tolerance-thing to the algorithm, but for now that's ok.
(https://www.syntaxbomb.com/proxy.php?request=http%3A%2F%2Fi.imgur.com%2FKmXAnhc.png&hash=a7a6624dc6437087644d3e9b5f0c91cfece48137)
Today my wife was nice enough to take the son and visit her grandmother (I am there on Easter weekend, so I can skip todays visit :-)). So I played a bit with Python and the scripting capabilities in Blender. Why?
I have rigged a character and animated it (walking, stair climbing, ... what I was interested in trying out). Now Blender isn't that friendly when it comes to reuse stuff on other characters. Also linking these characters into my main scene (where I have my lights setup, some basic tiles, multiple cameras according to the tile-size of the objects...).
Ok, my game should not use so much file space. This is why I only render every 3rd frame - and also I do not need every animation. Also I need the whole stuff rendered from multiple directions.
So during my tests I adjusted start,stop,frameskips and object rotation manually. Means with walk + idle I already had 8 adjustments, filename changes, ... and breaks until I hit "render". Filenames were also a bit "uncool" (frame instead of "frame rendered"). All in all it became more and more obvious: this is a tedious job if I plan to have 10 different characters (visually more attractive).
(https://www.syntaxbomb.com/proxy.php?request=http%3A%2F%2Fi.imgur.com%2F1fBmyvT.png&hash=5319a91600ae99b86f61d0cf8fd2e489f803cd0b)
So I wrote a little script which handles the stuff for me:
- defined "to render" characters, animations (name, start, stop, framestep ...) and so on
- iterating over them:
- - making the character of choice visible in "layer 0" of the scene
- - setting current animation stuff (start, stop, ...) (optional as I do single-frame renders)
- - rendering the animation frame by frame (skipping inbetweens as desired)
- - rotating the object (keeping lights etc on their position)
- - rendering again ... rotating again ....
While the script is a bit heavy now (cannot just abort stuff, so it runs except I "kill" Blender or it finishs the script) I am still satisfied to have learned a tiny new piece today.
Even with a single sprite rendering in ~10 seconds (I should really lighten the materials a bit, no need for pixar-style eyes and their exhaustive material setups ;-)) it takes a while "per character" (36 sprites for walking, 32 for current idling animation).
But once I finished doing the animations, the little variations in the characters ... I can execute the script, drink a cappucino and after a big while all the character sprites are rendered.
bye
Ron
Looks very VERY nice! :o The character have a definite personality about them.
Oo, er!, looks pretty unique :) - Is it some sort of sims / computer shop game?
hmm "Computer shop" - I planned to have some creature "shop" game: you create cartoons, CGI monsters, ... for 3rd party contracts or later on your own movies. Quality of what you do is based on skills the employees have + productivity mods the production devices inherit (simply spoken: a good computer makes things a bit faster).
The more often people do jobs the better they get in it and the more points they produce per "time slot" (second or so) - of course only if they are working on a production device. Just lurking around wont bring points for the production.
With finished productions (either given X points of a production aspect or a time frame ended) you earn money for upgraded or new devices, sending your employees to training programmes or maybe doing things like promotions of your own movies. Maybe "research" patents can be paid so you can improve base quality of aspect X without your own "while working"-research. "X improved render times by 10%".
bye
Ron
@Derron
That sounds like a really different and refreshing idea. You might be on to something there. 8)
Added idle + "search new target" to the units.
(https://abload.de/img/ezgif.com-optimizeofuoi.gif)
Please excuse the look - the black dude is not wearing a brown latex mask. Think gray hair (beard + eyebrows) does not look well in that size. Also the satin-backlighting looks a bit odd there.
Idle animation is a bit too subtle but I needed to redo it properly as I accidentally scaled the characters before animating the rig - and this lead to some probs during reset of the scales. Might add some idles later on but I am already on 30+ minutes of rendering time when doing 5 characters. So for now the animations will have to do and I should concentrate more on the game itself.
bye
Ron
My first impression was Sim Hospital.
Cool bots, :) curious to see what the gameplay is about.
Quote from: Steve Elliott on March 28, 2018, 16:29:46
My first impression was Sim Hospital.
My first impression was little computer people. Everyone remembers that, right?
Yes, I remember.
Used to love this:
(https://www.syntaxbomb.com/proxy.php?request=http%3A%2F%2Fwww.juutilainen.fi%2Flcp.gif&hash=8110aae696a5a3e6d9e000889e04cffbfc04f7ea)
Little Computer People - the predecessor of all sims..
Completely pointless of course, but fascinating to watch at the time.
You'd give the little fellow a command like "feed the dog" and then hoping for ever he'd do it, which most of the time he wouldn't- just ignored you, living his own little life. :D
I remember going through the code searching for which commands were allowed.
Quote from: Rick Nasher on March 29, 2018, 11:06:16
Used to love this:
(https://www.syntaxbomb.com/proxy.php?request=http%3A%2F%2Fwww.juutilainen.fi%2Flcp.gif&hash=8110aae696a5a3e6d9e000889e04cffbfc04f7ea)
Little Computer People - the predecessor of all sims..
The game had a feature where the look and character of the person you got when you first loaded the game was always the same. I doubt very much it was different code for different copies of the game so there must have been some algorithm involved in generating the character as there was no saving data on the tape version but every load you got the same guy.
David Crane is a very clever programmer. I was always in awe of how much content there was in the single-load Ghostbusters.
Afternoon nap for the son - so I had 1hr of playing around with Blender.
Created some low-poly stuff but as I am rendering them, I use a lot of subDiv to smooth out things. Maybe I need to do them even more LowPoly.
(https://www.syntaxbomb.com/proxy.php?request=http%3A%2F%2Fi.imgur.com%2FjnHS92i.png&hash=a80d22f3c378befc52a66569cd2a7d57de0efdc9)
Have some other stuff done too, but I do not want to disclose everything - basic idea is to have som "late 80s" or "early 90s" devices ready for the dudes lurking around.
(https://www.syntaxbomb.com/proxy.php?request=http%3A%2F%2Fi.imgur.com%2FBBCsVa8.png&hash=1e995d3bc67d1e46b277dcfe6a418ffc26cb3644)
I also added some spawning/vanishing mechanism so people start outside of the building and walk at first. They than do according to their task: try to find an unoccupied device or walking around in the building. Will add some coffee machines for spare time activities :-)
bye
Ron
Had a bit of time yesterday and created some movie equipment. Now, before leaving home I had the time to create some "IWasAdam"-esque skyscrapers :p
(https://www.syntaxbomb.com/proxy.php?request=http%3A%2F%2Fi.imgur.com%2F9sBLpda.png&hash=fa6084394cf929d8027b43dc8dd4a8a7e6afea74)
This is one of the "late 80s" special effects production device - there will be some "animatronics" or claymation thingy ... will see if it fits.
And yes, the wooden tables are by intention - we talk about the eighties (I know there were metal desks already but dunno, think it is nicer to have this look than an industrial/commercial one).
bye
Ron
brilliant :)
if you really wanted to be 80's furniture, then it should be Black Ash. it was all the rage with some colorful wallpaper at the time ;)
Black Ash was nowhere in our GDR homes :-p
Think the 80s desks need to bit way more "stuffed" (books etc) - things you do not have anymore on your desk thanks to the internet.
bye
Ron
Had less time than thought this weekend ... saturday with buddies, sunday with family (parents, brothers/sisters and their kids, ...). So I only had a very few hours to protoype a simple interface and add some interactivity.
Think I found some bugs in Blender (am not moving/rotating the cameras, but while my scripts render stuff they sometimes get moved out of the sudden...). Also learned how to use "random" input in Blender's material nodes to have different cloth/skin color tones on new character instances. Added also some small "shapes" so I could adjust nose size, breast size, ear size ... and so on. Fans of pigtails now also have a female (potential) employee to look at.
(https://www.syntaxbomb.com/proxy.php?request=http%3A%2F%2Fi.imgur.com%2FcG8Xqlo.png&hash=f5898bc8bcc47af44b9b00b3ef6addf07c5174f1)
There is no real game play added yet (the whole "project" stuff is "todo"). Dunno if I can squeeze everything in on tomorrow and tuesday's evening. If not you are just getting an application showing you some persons walking into a building, doing some stuff, walking out ... :-)
PS: yes, some GFX for borders/datasheets is based on some of my FOSS work in TVTower/DIG - so you might have "seen it somewhere" already.
bye
Ron
Does look pretty intriguing to what it's all about. Hope you get to finish it in time :)
(This is a copy of the post in the compo-thread)
(https://abload.de/img/logoqfp8h.png)
Linux: https://www.gamezworld.de/files/CreatureCorp.linux.7z
Win32: https://www.gamezworld.de/files/CreatureCorp.win32.7z
Some unneeded stuff removed (png files) - for the low-bandwith-dudes of us:
Linux + Win32: https://www.gamezworld.de/files/CreatureCorp.Linux_and_Win32.7z
(if the game is not running on your lowres-display: open up config/settings.xml and adjust resolution)
GameTitle: Creature Corp
OS: Windows + Linux
Based on: "Saving Mr. Banks" or "Time and Again" (documentary about Jim Henson)
While the game is far far far ...did I say it already? far... away from completition the base idea was to have some company running which solely purpose is to create cartoons, effects - and after some research also CGI movies.
As time was running out (and gui interaction stuff got pretty complex) it is more of a techdemo-kind than a real game (albeit I tried to plug in some stuff in the last two day's evenings).
(https://www.syntaxbomb.com/proxy.php?request=http%3A%2F%2Fi.imgur.com%2F7J7muhU.png&hash=4c7f683f00a40dd3ba6f21ea8163c6d6deabe283)
So start the game and hire some applicants to do the work for you. As there is no "custom production" now you can only use the auto-created "contract production". With the money you have you can buy new devices (just click on the paper-boxes laying around to open up the buy-dialogue).
To sell stuff you click on the devices and hit sell ;-)
(https://www.syntaxbomb.com/proxy.php?request=http%3A%2F%2Fi.imgur.com%2F3wzRqQC.png&hash=f2d6f1b5f214af197dd63b32ccd78676d68ecffd)
To fire dudes: select them and there they go.
With "tab" you could enter into some debugview, but there is not much to see.
With cursor keys you could move around on the map.
So this means:
CURSOR KEYS: move camera (if desired)
KEYS 1-4: adjust speed (time and movement)
LMB: confirm actions
RMB: cancel actions
(https://www.syntaxbomb.com/proxy.php?request=http%3A%2F%2Fi.imgur.com%2FjGgNb53.png&hash=1fabc7e96b87a36d9a83048f82c8b51783b5999a)
The game was written in BlitzMax (and should compile with NG). It features a person name generator for various countries, and a tile grid system written for this game (never done before).
As I always want to learn something with the competitions I tried something new this time:
- grid system
- sprite-split to automate sprite splitting from a "rendered whole item" into "grid pieces" for proper z-indexing/hiding
- automate stuff in Blender via python scripts (wrote some to render the various figure animations, item-views...)
- randomize stuff in Blender (variable hair/skin/cloth color)
Excuse again for this "tech demo" without sound/music ... you could add one via config (game is aware of playlists) but I thought it is not really needed to add SFX/music now - as the game lacks so much gameplay already.
bye
Ron
While the game lacks many game play aspects (custom production, "unit->device" filter/limitation, "produced production point"-bubbles and so on) it already contains a lot of stuff just not visible yet.
Maybe I made it overly complex already (with constant-getters, productionDeviceItems extending layerItems extending layerEntities ...) but somehow I think this is needed to avoid "includes" or mega-sized-main-files.
As mentioned I found some bugs in Blender which ate a bit of my sparetime: if you update objects via Python scripts the representation within Blender is no longer "up to date" (even with scene.update() calls). So elements appear as if they were rotated - moving them (grab/rotate) and aborting it (escape key) corrects it. Nonetheless I had some issues with the auto renderer sometimes rendering borked stuff.
With "low" rendersettings (576 samples) I rendered the "desks" in about 30 seconds for each frame. So each desk (4 directions in 2 states) rendered in about ~4 minutes. Render times for the characters were a bit shorter (at the end I was at about 20 seconds per frame). ~70 frames (avatar + animation) in 12 characters = 840 frames, .... think you get the render time.
Glad I automated much of this stuff. I also prepared some more items (plants, decoration stuff in the building) but after fiddling around with the "blocks seat-spot of desks or not"-checks time was running out. So sorry, no book shelfs, colorful flowers or other small things (power sockets for the walls, wall lamps ...).
The game is prepared to have "shadows" rendered in extra steps but I think with the current light-setup this is not needed.
To be able to render the figures _sitting_ at a desk I would need to split the sitting animation into "below" or "above desk" (via an "hide out" plane in Blender). This is the only way to allow an flexible rendering of "x chars vs y desks" (the other approach would be to render the desk with the figure as animation).
Hmm, maybe standing is already "good enough".
bye
Ron
I just recognized that I forgot adding another character I prepared... but nah, no worries ;-)
Meanwhile I want to share with you some details about the character animation + rendering.
(https://www.syntaxbomb.com/proxy.php?request=http%3A%2F%2Fi.imgur.com%2FsA9lBtK.png&hash=03fcfc395b24882f389800beb1e6e6351c424917)
As wrote earlier, I created the stuff in Blender. I set up a new .blend-file containing a basic grid (so you could add some stuff and render "including grid tiles") - it also helps to layout stuff on it (center on grid tile, size it so it fits to 2x1 tile etc.). There I also do the light stuff (adding a sun, some lamps defining the shadows, ...). Most important: I added some shadow catcher, so there is alpha-transparency shadow instead of having a shadow on a fixed underground color/grid-tile. There is also an "alpha hideout"-plane added which hides the whole grid/tiles from the render. For which reason is that needed?
Ok, all my grid tiles were modelled in a "expose ground/below surface" way. But as I was not sure how I finally implement stuff in the grid engine, I rendered most of them "without" that part (eg. to avoid "texture bleeding" when rendering them at floating point coordinates). But at least I learned how to do that stuff and was prepared to use it to my advantage.
So I had this basic scene setup and were ready to fill it with stuff. Blender has the nice "link object" ability. In essence you have two files and link one object,group,light... from file A into file B. File B only contains a reference then and when you update stuff in file A, file B will represent the changes then. It is a bit limited, you cannot link an armature from file A to C and a character/model from file B into C - and bring stuff together there. Nope. Does not work yet (waiting for many years now).
Ok, basic scene setup... I created another file with some basic character model for "man" and one for "woman". In Blender you animate armatures rather than the model itself. The characters were "rigged" (assigned to the armature and then the vertices were weight-paint-assigned to the armature's bones). Both character bases were using the same armature. This is needed, as the "animation" is stored for the armature. I did not want to do things multiple time (for each character) and am not yet knowing how to handle all the NLA-stuff (non linear animation). You store your animation ("move hand from x at frame A to y at frame A+10") in blocks but hmm...something to learn next time.
(https://www.syntaxbomb.com/proxy.php?request=http%3A%2F%2Fi.imgur.com%2FozCY2cf.png&hash=08d880bf5a4a356c5ed7a55971c9f05e90d60e7c)
Now I had 2 nude characters (nipples anyone? ;-)). I modelled some clothing: sakko, shirt, pullover, throusers, skirt, shoes, glasses, ... and also modelled the hair. So one could call this "props". These elements were also added to the basic armature (and weightpainted). So I could copy/duplicate them along and just alternate the materials to create some different "looks" already.
For each individual character I "linked duplicated" the models if possible. Means if I changed the original model, it changes the duplicate mesh data. But I was still able to adjust material on this copies.
(https://www.syntaxbomb.com/proxy.php?request=http%3A%2F%2Fi.imgur.com%2FVY7kiuf.png&hash=d8298e1be499d1f3c10569fd2af4e922650a6d8a)
Using some "random" material created a new skin-tone/shirt-color variation on each "linked copy" of the character/clothes object. Dunno how to "randomize" on command, but for now I just did it another time if the skin tone was not how I liked it to be.
I added this stuff to the clothing to. Created some "procedural material" for the pullovers, shirts ... to avoid use of textures.
(https://www.syntaxbomb.com/proxy.php?request=http%3A%2F%2Fi.imgur.com%2FyE6Ivw6.png&hash=ad376de7c8e2214e99899a070683ac3cf2243cc3)
At the end I created 12+ character variations - woman with long hair, pigtail, baldy man ... And I added some simple shape keys to the character model so I could adjust ear size, nose size, breast size... . Basically you create a "base shape" (store current mesh) and manipulate the mesh then (eg. resize ears). Then you can morph between "base" and "new shape" (only changed vertices are taken into account - so you can mix shapes).
Finally I linked in all the characters to my "main scene". Rendering them out now would become tedious - bringing a character to the right render layers, renaming output file, setting which frames to render and what to skip for this kind of animation (rendered every 3rd frame when walking...). So I wrote the scripts I talked about earlier. They automated most of the stuff - at least once I "finished" them.
I extended the script to also change to a "avatar camera", change light setup ... and render "faces/portraits" of the chars. They are used in the person-datasheet (applicants, employees).
Enough of the insights, dunno if someone was even interested in it.
bye
Ron
A lot of work went into the animations and graphics it looks like. I read your posts above but havent played it yet...writing this on my phone.
the modelling and animation is extremely well done - I love it.
So people here seem to like the visual representation and the basic/described idea ... so I ask you:
- what would you like to be able to do in the game
- how much of the tasks should be done automatically (searching "useful" working shifts, the right device for a persons skills ...) and what should be done by the player
- how "difficult" should it get?
- singleplayer - and if multiplayer, competitive play?
bye
Ron
Well to kick this off, I think 2 of us saw Theme Hospital when looking at the visuals and animation. A possible route to take.
When I first saw this I thought "Cool, a computer shop simulator". That's the direction I'd take with this. There is loads you could do for a computer shop simulator. If you don't fancy it then I may have to do one :P
If we're taking the above idea then there is 3 key areas :
1.. Sales people
2.. Technical people
3.. Stock management people
Each of those would have a whole heap of individual tasks to do and that leads on to quite a nice management sim if done right.
I know this is not what you are aiming at but a specific shop sim could work really well.
QuoteSo people here seem to like the visual representation
Very much so. Immediately you wonder "What's this all about?" and that's a great catch.
@ "The Crazy Computer Corner"
I am pretty open concerning the theming - as long as the "mechanics" are nearly the same - or equally "extendable".
This is my main concern with "computer shop". Ok, so you start with eg. one employee (you - or you + buddy).
You have multiple "stations" in the store:
- storage racks where people take the items they buy
- info points: people could inform about stuff there
- cash-point/check-out where people pay for the stuff
- repair point, where people bring in their stuff for repair
- background: stock management
- optional: "lounges" showing cinema speaker-setups, big screens ... increasing a modifier for "buy item X" (above a level and figures will buy it)
- optional: advertisements: walking by them, raises interest in something ( more about in the next sentences)
- optional: ...
So people would go into the store "looking what's where" or "have to repair something". They lurk around the storage racks. For each potential buyable item they have some kind of "interest level". Interest levels are raised by moving buy a storage full of that items, by "lounges" - and by talking to people at the info points. Once a specific level is reached, that (and maybe only that) item is tried to get bought. So "customer" takes an item (lowers availability) and brings to cash-point. As soon as the item is taken from the shelf some kind of "impatience timer" is starting. As soon as this is running out without having paid for the item, the customer brings it back to the shelf!
Why? Because this way you are enforced to always have enough cash-points so to avoid long queues at them.
Ok, your employees would have "stats" (trainable, improvable by "excercising" it). So cashiers get faster (modifying "cashing time" by up to X percent) and so on.
So far...so good. BUT back to what I initially planned to write about (but first needed to explain what I think you were trying to "sketch out"): how to scale endgame? You could increase "storage area" (bigger store), hire more employees ... and then? Is the whole game about "store management" or is there something "more"?
Of course you could add "phone orders" (talking about the 80/90s) or later on "online shops" but they have different "game mechanics" leading to something totally different. Or they just look "grafted". Just think of 1-2 extra sections/departments in the store. There you can add computers and hire people to code the shop, then you have a section for "order management/shipping" ...
Another solution would be "multiple shops" but I think "simulation" will become pretty cpu-heavy (except you "simplify" stuff then, so people wont actually "walk" bout just wait a second and then do something "random task")
In "Creature Corp" the endgame would be to produce your own movies and to research tech to be "ahead of the competition". So in essence: what would be the endgame of the "Crazy Computer Corner" game ?
bye
Ron
I had to fire this one up again to get a feel for it.
I love the look and the little people. mechanics (the top bar, drop downs, windows i thought could be (hmmm) better, simpler, that sort of thing.)
ok. me thinks for a while.
I like the little people and the style. and I really like the concept of a computer 'repair' shop. it speaks to the geek in me. oooooh. "Speak To The Geek" has a nice ring about it for a title?
if you take the general concept of transport tycoon and rollercoaster tycoon. you have a (general) goal and try to get to it - time, money, people, etc.
E.G.
you have 12 weeks to fix 12 computers
you must employ 5 people at end of week 3
you must have 24 people come into the shop in one day
you must make 1000$ in one week
so...
that means you have money, a timescale (days), people, things to buy/mend and must manage them.
lets assume it is a computer repair shop.
it need 2 things:
1. the front of the shop - how many people can be served in it, possible displays to entice people in, counter to serve people at. wall with door to back of shop where the computers are fixed
2. the back of the shop - here you have desks where things are fixed. you need to buy in parts, fix things and send them out. antivirus would need someone skilled in software, etc
There's legs in this concept :)
So your gameplay would consist of the "management part" (hire/fire/... and buy spare parts) + "missions" ?
I think "bigger games" need some bigger - or harder to achieve - targets. With harder to achieve I am talking about stuff which is required for a target but is only available once you did something (eg. you need to research something first, or you need to have employees with "software programming" skills of lvl 10+ ... or such a thing, and level 10+ is only reachable once you sent the employee to some kind of studying course ... and the likes).
Why am I asking for such a thing? It can and will get repetitive to soon if you cannot "explore" something new during playing the game. It wont be a 5 minute-per-session thing so you need to provide some variation, motivational stuff for the player. Which is why many games add "events" (desasters anyone? ;-)) and some kind of tech-tree (which limits the beginner-stages and provides "individual development"). The limitation of a "repair shop" should somehow become "realistically" overcome. So a tech tree "repair mouse -> repair keyboard -
> repair complete computer" sounds as if you took the player not serious ;-). With repairs the only limitations are things like: to reprogram a bios you need to have a bios flashing utility. The steps to do that are the same for installing windows then. So this is what makes me a bit "uncertain" if it works. - in other words, such issues need to get tackled before as you else start creating something which then does not work at the end.
In short: how would the game "evolve" while playing, what would get added as available functionality later on, how to keep "continue playing" motivation up?
@ GUI
Yes, I wasn't satisfied either. I think the datasheet visuals itself are OK and look well suited for a "manager sim" while the top-hud was something I put together in < 10 minutes just to learn how to properly "cut out" layers from others in Photoshop while maintaining editability and not creating complex shapes (boolean combined vector shapes) - as I wanted to be able to colorize the "input areas" (the "cut outs" and underlayed parts). Also instead of "lists" for items you could have some kind of "area".
In TVTower I did it this way - and would do that in such a game too, if the items are "limited":
(https://www.syntaxbomb.com/proxy.php?request=http%3A%2F%2Fi.imgur.com%2FYfcnTLw.png&hash=eafe768a2a011b570311b5c242950be3b1c25aff)
(these images are vector based ones - as this fit more to TVTower now, but I would of course render things out to keep style consistent)
So this would work for eg. 10 "fixed" items but of course not in a dynamically sized list of employees, applicants, supply companies ...
PS: I am not against coorporating in such a thing with somebody "equally" (or better - like you and qube) skilled**. I do not want to assist someone doing his first game so there need to be a bit of knowledge in handling things, squashing bugs, .... I also would not really mind if someone wants to use another language (so acts as a coder) as languages are exchangeable - or learnable ;-)
Edit: with ** (equally skilled) I mean should know their "profession" a good bit. So if you hardly finished your first pong clone but created cool renders or music, you are still "equally" skilled (or even better than me). And if you cannot do anything of it you might be suited for social media interaction or finding game play ideas / writing texts / ... there is always a lot to do in such game projects - even tool writing is required here and there (thinking of my python scripts...ouch).
bye
Ron
There is one area (which I know you are very keen on): Linux development of my apps.
My problem is I have no experience with linux and it always ends with me shouting quite a bit.
The other is monkey2 - I have given up with Marks version and attempting to keep up to date and went my own way - so I am using a custom monkey2 which works really well.
How would you feel about me giving you my version of monkey2 and seeing if we can get them to completely cross compile?
I would need to make me a bit comfortable with m2 (so it works on linux). Next thing would be to make it compile your version (so we get native linux binaries) - and then making your stuff work - which I assume is the most complex part (for me) as it involves the OpenGL stuff and the likes.
IF you do not care exposing your m2 changes, you could create a new thread (worklog or so) about your m2 version - so others could tackle potential problems too. That way we get your m2 more probably running on linux (or other platforms).
Same for your engine: if you intend to open source it, create a worklog (engine + simple sample) for it and people could try to make it run on Linux/Windows with less problems. If you do not want to disclose the source, this parts could be done - of course - via email too.
That "simple sample" is useful to avoid to scroll over hundreds of project specific lines - and other things which _might_ have trouble on linux (asset loading and the likes - dunno how mature "[your version of] monkey 2" is in that regards).
So yes, I could try to get it run on linux - but no guarantee that it will.
Nonetheless it is always a good idea to install VirtualBox and create a VM in which you install Ubuntu - or Linux Mint (so one of the most popular distributions). For normal libraries you would find a big pile of tutorials on how to install stuff or tackle trouble.
bye
Ron
QuoteUbuntu - or Linux Mint
I did both and couldn't get anything to operate properly :/
My version of mx2 compiles without flaw on both osx and windows... with the same code and no changes!
"without flaw": I was talking about to first get m2 running here (did not try yet) and then this would be used to compile your m2 on the linux box then.
As said - if you want to do that "publically" then create a new thread, else send the stuff via mail (ron @ gamezworld.de). Take your time, am out for today (helping brother + BBQ and drinks)
bye
Ron
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 (https://github.com/blitz-research/monkey2/releases/tag/v1.0.5)
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?
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
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.
(https://www.syntaxbomb.com/proxy.php?request=http%3A%2F%2Fi.imgur.com%2FZXNqhxr.png&hash=758da7dd90045e376a1c62d2e11c060b20024c46)
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
Quote@ 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 :)
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
QuoteWhat 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.
QuoteWhat 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.
Quote@ 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.
QuoteBenefit 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.
QuoteI 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.
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.
@Qube do you know if agk supports monkey2 language concepts - oop, lambdas, etc?
Quote from: iWasAdam on April 17, 2018, 11:04:57
@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 :)
@ 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
@ Derron - what version of Linux are you using :o
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...
Quote
@Qube do you know if agk supports monkey2 language concepts - oop, lambdas, etc?
Quote
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 ;D
$ 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
Linux Mint Sylvia 64 xfrce
Right I'll see if I can get it working....
linux mint -check
install -check
get monkey2 1.05 -check
do strange sudo installs - check
begin rebuildall from monkey2 - check.....!!!!!!!
Good Lard... It's compiling!!!!!!
I've tried 4 different linux configurations, and numerous forum posts and still couldn't get anything to work.
This is the first time I've got this far....!
HOLY CRAP!!!!!! IT WORKS
Quote from: Derron on April 17, 2018, 11:51:22
@ 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".
Yes, you can split up your code and call it via includes ( or Insert as AGK calls it ). Coding big projects isn't an issue at all plus OOP is just another way of working to which I've never come across any game that couldn't be done without OOP. Neat code wins every time :)
I've written the more complex GUI's too, with Windows, buttons, sliders, radio buttons, list boxes, drop down menus, popup menus etc etc. I just find them incredibly boring to code :(
Quote from: Derron on April 17, 2018, 11:51:22
@ 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".
I aways envisaged it as a single player game and as far as the game is concerned there are no other stores. I think having other stores you are fighting with could work out but I would be hesitant to have that a a big side to the game.
Quote from: iWasAdam on April 17, 2018, 14:45:01
Linux Mint Sylvia 64 xfrce
Right I'll see if I can get it working....
linux mint -check
install -check
get monkey2 1.05 -check
do strange sudo installs - check
begin rebuildall from monkey2 - check.....!!!!!!!
Good Lard... It's compiling!!!!!!
I've tried 4 different linux configurations, and numerous forum posts and still couldn't get anything to work.
This is the first time I've got this far....!
HOLY CRAP!!!!!! IT WORKS
AGK, download, install go - on Windows, Mac & Linux. Simples ;D - Why torture yourself :o
( thread derail over )
As Adam suggested some kind of "sketch" (ascii gfx):
How would you tackle to disconnect "units" from "persons". For now I have persons - which are non-graphical and contain properties like "nameFamily:string", "wage:int", "hiredTime:Long" and corresponding methods ("CalculateWage()", "GetWage()" ...)... These "persons" do know to which production device they are currently assigned to (via "productionDeviceGUID", so only a weak reference). I also store actions/tasks (going to spawn point, search new production device, working at a device, idling, ... finite state machine).
Then I have added some methods to these persons which are called by the game: onReachTarget(params), onAssigntoProductionDevice(params) ...
The visual representation is done by a "TileEntityUnit" class which holds a reference to the person (could be accessible via personGUID too...). It knows the target on the tile map - and does the movement and rendering. For now it also handles action/task updates when reaching positions/targets - or if "inbetween checks" show that a target is no longer valid (eg. someone else is using it now, or the target got sold/ path blocked). I know this could be done via events too (persons list if other persons use a device now and stop their task then).
The "person" class (and other "game objects") do not know about their tilemap representation - I try to encapsulate as much as possible to avoid circular dependencies (and potential memory leaks).
Ok, so the visual representation interfers with / controls behaviour of the person class - which is what I worry about. It feels like a "dirty hack".
So normally I would think that "person" should know where it goes to ("target position" or "target object") and how long the route will take (in "game time" - so it allows various game speeds, like I already added with keys 1-4). The "TTileEntityUnit" would just represent the visual state and should in no way be required to modify "person"-properties.
In other words: how to bring together "tilemap" (iso or top-down does not matter) and "non-tilemap-objects": in other words, how would you make it "client-less"/"head-less"?
bye
Ron
It looks like you're overcomplicating things :o
Very roughly and cutdown, I'd just define things like so ( using wacky AGK code :P ) :
Type tPerson
id
name
wage
hiredTime
jobTitle
currentAction
xTile
yTile
EndType
Type tDevice
id
name
currentState
hasPerson
xTile
yTile
EndType
Then you can easily parse through each person to update them, see what they are doing etc and just as easily parse though devices to see what state they are in, if any person is at them.
I think going OO nuts is not the right or easiest approach.
Same with game speed. If you code it for a target frame rate of 60FPS and assume that is normal speed then it's easy to speed up the game based off deltaTime. The speed of characters walking, the time, time it takes for a task to complete can all be linked very easily.
BTW my person type looks like this for now:
Type TPersonBase extends TEntityBase
Field lastName:String = ""
Field firstName:String = ""
Field nickName:String = ""
Field gender:int
Field countryCode:string = "US"
'wage + modifier (more expensive at same skills)
Field wageMod:Float = 1.0
Field wageBase:int = 0
Field wage:int = 0
'paid for todays work?
Field wagePaid:int = False
'reputation a company has to have before applying for a job
Field reputationMinimum:Int = 0
'when born?
Field timeDOB:Long
'when hired?
Field timeHired:Long = -1
Field hired:int = False
'got fired meanwhile?
Field timeFired:Long = -1
Field fired:int = False
'individual skill values
Field skillLevels:int[]
'how many times a skill was used (for level ups)
Field skillsUsed:int[]
'what skill was used for last production point
Field lastProductionPointSkillType:int
'when was the last skill point created?
Field lastProductionPointCreationTime:Long
'influencing productivity of that person
Field productivityMod:Float = 1.0
Field assignedProductionDevice:TProductionDevice
Field assignedProductionDeviceTime:Long
Field assignedProduction:TProduction
Field assignedProductionTime:Long
Field actionState:int = 0
Field actionStateTime:Long = -1
Field actionStateWorldTime:Long = -1
Field nextActionStateWorldTime:Long = -1
Field currentTask:int = TPersonTasks.NONE
Field currentTaskTime:Long = -1
Field currentTaskWorldTime:Long = -1
'energy
Field energyRecoverAt:Int = 50000
Field energyRecoverTo:Int = 60000
Field energyRecoverLevel:Int = 0
Field energy:Int = 100000
Field energyMax:Int = 100000
Field energyUseMod:Float = 1.0
Field energyRecoverMod:Float = 1.0
Field energyUpdateIntervalMod:Float = 1.0
Field lastEnergyUpdateTime:Long
'working times
Field workStartHour:int = 8
Field workEndHour:int = 16
Field workHours:int = 9 'including break
Field workShift:int = 0 '0 early, 1 = mid, 2 = evening, 3 = night
Field workShiftsUnwanted:int[]
'ATTENTION: for now you can simply cheat employees into working more
' by changing their shift :-)
'TODO: Save new SetShifts() into other variables and when
' a current shift is planned to start this new shift values are
' copied to the real used variables and time is checked again
Global skillsUsedLevelUps:int[] = [10, 50, 100, 250, 500, 1000, 2500, 5000, 10000, 25000, 50000, 100000, 250000, 500000, 1000000]
Const energyRecoverLevelMax:Int = 3
[...]
(yes, getting fired is something else than setting "hired to false")
What you do is adding things like "tile position" to the person/device - something they normally should not know about (or even care about) - separation of concerns. But as "xTile" and "yTile" are simple integer values, I think that's "ok" to make things easier. And yes, I thought about that too (main idea is always to allow "separation" to avoid circular depencies - so no tileX=TTileobject but tileX=102)
Ok, so "TPerson" now is able to know where it is located on a map (xTile,yTile). Moving to another object would need to go about an object "controlling everything": "world.GoTo(person, xTile+10, yTile)" or so. Why? A person should be able to target items (but of course should not need to know that it is "on a map" - so it just needs to say: please go to the item). It also should not know about "TDevice" as "TDevice" knows about "TPerson" already - I normally create some base classes for that (TPersonBase, TDeviceBase) which could get used by the other classes. These base classes only contain "encapsulated" data or base data (int, float, string, list). As said, to avoid circular dependency. In the base class I could have things like "GetAssignedPersons:TList()" which returns nothing in the base class, but a real list of person(base) in the "TDevice" class. In C/C++ you would surely use "interfaces" for this, but BMX(vanilla) does not have this, so I am used to use these to keep vanilla compatibility.
I am aware that many problems are "self-made" as it over-complicates stuff. I could just have TPerson and TDevice in the same file and they could happily access each others properties. But for me this does not look "clean" - while of course it cuts down development time and eases a lot of pain. In AGK this will work that way as there are only "includes" (so they are "in one file" already - somehow). With "includes" the whole thing is a lot of easier to code but I am not sure how AGK (or others) do the Garbage Collection then.
I should really do not care much about "reusability" (I always think one could use a class in another scenario - so encapsulation makes this pretty easy).
Also I always try to think of objects using "natural thoughts". A person does say: "I want to go to the computer", it does not think "I want to go to the computer which is located at the left corner of my office". So the persons in the game should not care for tilemaps - they just need to know that the computer exists, and if they are at it or not - and that they could go to it, or not ("already occupied"). Maybe doing it that way is overcomplication - similar to having total "normalization" in Database schemes - sometimes having "dirty" DB-structures helps speeding up things (adding indices to remove some queries and so on). Hmm should really try to "keep my code dirty" :-).
Let's also check what Adam suggests - how he would tackle such things (he seems to be a "procedural guy" too - albeit using Monkey2).
@ Game
If you want to code something in your evenings: feel free to use the assets of my game as place holders so you do not need to stare at rectangles or such a thing.
also here is a simple iso-rectangle / iso-block code for prototyping - might save you 3-4 minutes of thinking about it:
Function DrawIsoRect(x:Float,y:Float,w:Float,h:float, filled:int = True)
if filled
DrawPoly([x, y + 0.5*h, x + 0.5*w, y, x + w, y + 0.5*h, x + 0.5*w, y + h])
else
DrawLine(x, y + 0.5*h, x + 0.5*w, y)
DrawLine(x + 0.5*w, y, x + w, y + 0.5*h)
DrawLine(x + w, y + 0.5*h, x + 0.5*w, y + h)
DrawLine(x + 0.5*w, y + h, x, y + 0.5*h)
endif
End Function
Function DrawDemoBlock(x:Float,y:Float, height:int, tileWidth:int, tileHeight:int)
height :+ tileHeight
if height > tileHeight
local oldCol:TColor = new TColor.Get()
oldCol.Copy().AdjustBrightness(-0.2).SetRGB()
DrawIsoRect(x,y, 2*tileWidth, tileHeight, True)
DrawRect(x,y - height + 1.5*tileHeight, 2*tileWidth, height-tileHeight)
oldCol.SetRGB()
DrawLine(x + tileWidth, y + 2*tileHeight - height, x + tileWidth, y + tileHeight-1)
DrawIsoRect(x,y - (height-tileHeight), 2*tileWidth, tileHeight, True)
else
DrawIsoRect(x,y - (height-tileHeight), 2*tileWidth, tileHeight, True)
endif
End Function
bye
Ron
QuoteI am aware that many problems are "self-made" as it over-complicates stuff. I could just have TPerson and TDevice in the same file and they could happily access each others properties. But for me this does not look "clean" - while of course it cuts down development time and eases a lot of pain. In AGK this will work that way as there are only "includes" (so they are "in one file" already - somehow). With "includes" the whole thing is a lot of easier to code but I am not sure how AGK (or others) do the Garbage Collection then.
I think the main thing is to code in the style you are most comfortable with. There is no right or wrong way, just the final result. No idea how garbage collection is handed in AGK, it's not anything I worry about.
Lunch break and I reorganized my blender files ... some "offsets" were not clear to me (only happening in the file linking to an asset) - I just parented that stuff to new empties so I rotate/position the "empty" then.
(https://www.syntaxbomb.com/proxy.php?request=http%3A%2F%2Fi.imgur.com%2FVNZT8gA.png&hash=97a36baa20fd90a4b689fe2d9fd37fa833806d99)
Also created some "target empties" so the script knows to where it has to move stuff - which allows adjustments without altering the script then.
bye
Ron
very nice :)