ID:89636
 
Keywords: projects
Beware ye the wall of text.

Some may be aware that Tayoko and I are up and about once again. Some of those who do may be excited for us to make a new project. Some may just want us to go back and finish Efencea (Tower Defense). Yes, we have to distinguish it. Our latest project just flopped. We were working no Efencea Role Playing Game Arena. The Arena bit was due to the fact that we've gone through three separate design documents for ERPG, each drastically different. So, we decided we would just pull our combat system and build a game around it for a simple project--ERPG Arena. Possibly revisiting it a bit later, after we finished it, and fleshing it out into an entire game. Even the simplified version was going to be a ton of work, at least for Tayoko.



Our first step in developing was to discuss at length what we wanted in the combat system. Then, after we had spent a good long while coming up with what we felt to be a somewhat unique and enjoyable set of stats and combat gameplay, I spent a night coming up with questions that would serve to set into stone the system. The second step was answering all of those questions, which took a few days. At this time, we came up with the base-most elements we would need to prototype the system. A set of simple placeholder graphics, and a working prototype (in code; including stats, enemies, skills*, simultaneous turns, losing, winning, etc.).

Part of the prototyping was to flesh out all the animations we'd need, and how large the player sprite would need to be. Tayoko intended to digitally paint the combat graphics, rather than pixel them. It was interesting, our player sprite encompassed a 512 x 416 space, or 212,992 pixels. Seeing how Tayoko estimates that he can pixel 10 32x32 frames in an hour or 10,240 pixels per hour, that would mean a single frame for the player sprite would take him almost 21 hours to finish. Digital painting and then applying pixel touch-up would take far less time. Even still, our design called for twenty five frames for the sprite, and 25 frames for all overlays. A ton of work. I cut this down to 5 frames via use of the IconProcs library by generating some of the repetitive states (Dodging, Entrances, and Death).

Anyway, to the point, 512 x 416 was far too large. We didn't care about the size of the .rsc, we knew it would get huge from all the oversized images. Even Dream Maker began to not compile in an instant as it always had for me. I noticed there was a problem when loading up the prototype equipment took several moments. The CPU spiked to 50% momentarily and the memory usage jumped from about 15,000K to 274,776K. My jaw dropped and I was sad, haha. Needless to say, this multiplayer game would not run well multiplayer. I'm not even certain it would run well single player. I'm just confused how a 500KB resource becomes 275MB in memory. Perhaps it's a BYOND issue.

Feel free to try out the prototype: Prototype.zip

We had plans to make the equipment highly customizable, at least in an aesthetic sense. The combat in the prototype isn't finished either, It most definitely wasn't going to be BYOND input popups--you won't see them unless you try multiplayer, but they're there.



So, what now? We've been tossing new ideas around. We've had quite a few too, which is part of the problem. We can't settle on anything. The other half of the problem is that all of our ideas quickly become extremely complicated and too large to develop in any decent amount of time. I blame this in part on Tayoko, he has this overbearing urge to introduce new and exciting aspects to the gameplay--something I call the Tayoko Spin.

Some of our recent ideas are below:



Code Name: CQ
Tayoko wrote up a beautiful abstract design document detailing the rise and growth of societies. It focused on the harmony needed between government (military), Economy (resources), and Society (influence).
"The primary goal of an empire is to expand power. The fundament of power in an empire could be broken down into three elements. These elements of power include economic wealth and control of resources, government dominance and enforcement of rule and regulation, and the structure of society and its functions. Each relies on the rest; all co-existing in harmony."


This would more than likely turn into a Civilization-esque game, but with a large focus on units, or groups of people, their use, and growth.



Code Name: Action Avatar Town Defense
I had a moment of inspiration that begat this project. Here is my synopsis:
"Players are gods who give their blessing to a fledgling village on the outskirts of the territory of man. However, a god must not exert themselves in the realm of man, lest they expend their immortality, and thereby must choose an avatar to carry out the majority of their benison. Upon the exaltation of their chosen avatar, a god may bestow hallowed gifts, be they raw power or manifested holy objects. Even still, evil is afoot and has no love for man and their gods..."


Players would start the game viewing a tiny village, or possibly the construction of a town hall. The town would have a random assortment of AI villagers that ran around carrying out mundane tasks, fetching food, running errands, building, cooking, cleaning, and everything else that is involved in running a town. The players, being gods, are the protectors of the town, and choose an avatar. The avatar would be any villager the player wanted. So, I might choose a miner bless his pick-axe with all my available godly power and then play as him in the defense of the town with his uber blessed pickaxe. Random events would determine the fate of the village and the game would run until the village was destroyed. One game the village might have a slime problem, slimes keep pouring out of the sewer and must be fought back to whence they came. Another might see the town grow to a decent size only to be wrecked by a ferocious dragon. I had ideas as to the random construction of shops by NPCs with the required talents, caravans of goods coming and going from the town, among other things.



Code Name: DNA Man-Pets
This was a fun idea. We take the typical pet game, and flip it around such that you play a monster (an alien) that has a pet human. The concept was that aliens were secretly in control of the Roman colosseum and ran their human bloodsport. Players would be an alien that trained up a human via the use of genetic (magical realism in play here) alteration. The genetic alterations would explain the various myths of the time. Medusa would be a woman merged with snake DNA, for example.



Code Name: Blue Mage Taken Roguelike
We've wanted to do a roguelike for awhile now. This would be an Efencea themed game that involved one of our concepts, the Taken. You, the Taken, would seek out Efencea inside dungeons whilst learning the abilities of your enemies. This was the result of last night's discussion, so it doesn't have nearly as much detail as any of the others. We were toying with the notion of not including death or saving and some other things, which is where I called too much Tayoko Spin and quit discussing ideas for the night.



Phew, I got a little lazy on some of the idea descriptions, feel free to ask questions.

If you read all of that, excellent, you can easily consider yourself a fan! Thanks for your support, comments, and time.

This took a long time to write up!
Want some advice from ProNoob? I guess you are using map control and client.screen to display the images and animation so I have a question, do you use flick() to change onscreen obj's state or maybe you do it manually like icon_state="attack"? If you are using second way I advise you to use flick(), it shouldn't lag if you use that - I tested it. If you were already using flick then kill me.
I was right. I used your icons and my version works fine without any lag. Max RAM usage was 50MB and max CPU usage was 3.

http://www.sendspace.com/file/i8po8h

Also, I noticed something wrong in byond games. When I have google chrome opened the game has bad spike lag from time to time. When I have google chrome closed, everything is ok.
ProShogun wrote:
I was right. I used your icons and my version works fine without any lag. Max RAM usage was 50MB and max CPU usage was 3.

You were wrong. You didn't do was use any equipment overlays, each of which adds about 50MB to the memory usage. You haven't found anything useful to us, considering your version still uses 50MB of RAM which is waay more than the simple prototype should. In my version, if you don't use equipment it should be around 50MB as well.
I'd rather you just finish Efencea. :P
Foomer wrote:
I'd rather you just finish Efencea. :P

We keep changing our list of things we plan on working on, but Efencea (Tower Defense) is always on there.
The 50% CPU is likely the icon processes you mentioned, and the memory usage sounds like a leak or bug in 'em.

Have you tried exporting the generated icons and just including them in the compiled resources? If you didn't need to generate them at runtime, the 50% CPU should disappear (which should only be on the host machine), and the memory usage should be much lower and constant. If BYOND is doing something funky with the icons (making them larger than necessary?), exporting them might also reveal that.

Although, some of those new project ideas sound interesting :P
I'm so mad ERPG Arena didn't work out. We had an excellent combat system planned out for it. Oh well.
20 hours for an image of that size sounds about right, based on my experience. While working on Regressia it took about an entire day to complete a boss image once I figured out how I wanted it to look. By an entire day, I mean about 16 hours.
DarkCampainger wrote:
The 50% CPU is likely the icon processes you mentioned, and the memory usage sounds like a leak or bug in 'em.

The frames are generated and stored before I plug them into the game, so, this isn't the case. With such large images, generating takes upwards of a few full seconds to complete. It's needless to say I ftp()'d myself static copies.

Have you tried exporting the generated icons and just including them in the compiled resources? [...]

Yep, I had no intention of generating them at runtime, but prior, with little utility snippets. I'm almost certain BYOND is doing something wonky with the images. Why else would 500KB become 275MB in memory.
On that note, maybe I should take it to the forums.
Strange. Does profiling reveal what process is eating all the CPU? (Chances are it's the same one eating the memory)
Profile results (total time)
Proc Name Self CPU Total CPU Real Time Calls
---------------------------- --------- --------- --------- ---------
/equipment/New 0.836 0.836 0.836 5

Which consists of:
New()
..()
image = new(image, layer = LAYER_EQUIP)

and an /equipment definition:
equipment
weapon
protoClub
image = 'protoClub.dmi'

Nice that these don't preserve tabs.
Vermolius wrote:
On that note, maybe I should take it to the forums.

Onward, to the dev forums!

What did you guys think of the other game concepts?

The descriptions only lightly touch the surface of each idea, so feel free to ask for more info.
I made a bug report, despite not knowing if it's a bug or not.
The Report
So say it is a bug issue and whatnot, and Lummox fixes it. Would production on it begin once again?
Ganing wrote:
So say it is a bug issue and whatnot, and Lummox fixes it. Would production on it begin once again?

We're currently discussing that possibility. Also, the possibility of bringing the sprites down to 2x2 or 4x4 in size, if nothing else.

Wow, I didn't realize you had 175 icons of that size! That would definitely explain it.

Along with sizing them down, I wonder if there are some other ways to cut down. For example, if for dodging you generate all of those faded states, maybe you could just use one full state, and then layer white squares at different opacities over them to get the desired "trail" effect?

Assuming all states are the full [512 x 416/smaller] canvas, maybe you can crop some of the smaller ones to increments of 32 or something (arms, head, ect). This adds more work on lining them up, but based on what Lummox said in his comment, the blank space is taking up just as much RAM as the rest.

That said, hopefully just working on a smaller scale will be enough and you won't have to resort to such laborious workarounds ;)
This is definitely a memory leak issue cause the dreamseeker.exe process lingers around after you close the game down.
Metamorphman wrote:
This is definitely a memory leak issue cause the dreamseeker.exe process lingers around after you close the game down.

Are you sure? I haven't seen that happen on my end.

Page: 1 2