TIGSource Forums

Game based on a LudumDare entry. My (8 year old) brother is doing the art, which probably isn't the best quality.

This game is quite a lot like SimCity Classic (the old DOS game), but contains more stuff and will hopefully be more fun.  :handjoystick:

There's also going to be a multiplayer mode where you get your own spot of land on a master server, and can interact with everyone else and their plot of land. Start wars, trade, etc.

Basically, a mix of MMO and SimCity..

Also it's written completely in Python. Quite ambitious, and will probably never get finished, but will be a nice learning exercise.  :coffee:

I do find this ambitious, it gives you and your brother a chance to practice skills :) I hope you both enjoy yourselves! Seems like a fun project :P I would look forward to playing it  :beer:

• Engine (it uses Pygame and has a system of states, elements, and movers.)
• Layers system
• Elements (Basically like objects in Game Maker)
• States (Big elements that represent the scene)
• Movers (Like MMF2's various movements)
• GIF generator (the title image of this post)
• Debugger (A generally useless one, but does work for simple tasks)
• Not much else except thoughts.

(Also, thanks a lot Joey!)

:handthumbsupL: Props for delegating a task to your little bro (I'm assuming you are the older brother :lol:). I wish I had a brother like that. Hope y'all have fun with this project.

That looks pretty good for an 8 year old!  Can't wait to see what he can do in a few years time...

Credits:


I quite like my GIFmaker. The credits are actually a giant button.


The engine is a class that contains all elements, states, and performs actions such as killing elements, updating stuff, and switching to a different state. It also has some functions for getting elements, player input, and image content.. Are god classes a bad thing?  :durr:

Elements are like objects in Game Maker. Each has their own position, image (even when it's invisible), Mover (Much like MMF2's movements). Movers are objects that basically just contain a position, and are assigned to an element. They are the objects responsible for moving around elements, and can be drop in replaced for any Element.

Element with a Mouse Controlled Mover will follow the mouse, but if you replace it's mover with a Static Mover it will stay still. You can swap out an Element's mover at run-time, or override its default one at Element creation-time.

Since pygame is pretty slow if you just redraw the screen each frame, I'm using a system where each Element has a property called dirty, and if the element is dirty, it will be rendered, then undirtied. An element will be dirtied if it has moved since the last frame, if it is colliding with another Element, or if the element just wants to be dirtied.

If an Element is beclouded by another element completely, it will not be dirtied.

So that's that. The credits in the GIF is actually a button with the Falling Mover, and will disappear when clicked.

Perhaps I shouldn't be posting the technical stuff in the Devlogs section. :facepalm:

But it's all that's really happening at the moment.  :shrug2:

More later! (not that anyone cares)

Corazon: Thanks!
GeoffW: My bro says thanks!

Interesting structure :) I've been making my own small Engine in AS3 the past few days whilst remaking pacman to test it ahaha! http://myswftesting.net84.net/picmin/bin/ (http://myswftesting.net84.net/picmin/bin/) - if you want to look at it ( wait for load, press P to start after splashscreen, WASD to move )  :) but yes, I wish you both good luck and I will be checking this thread often for updates  :beer:

PS. The Pacman game thing doesn't render text properly, need to fix it :) and I know sound/etc is horrible, it's just to test the engine :)

This sounds pretty interesting. Cant wait to see some screenshots. :handthumbsupR:

Working some more on the engine. Trying to have a sane way to let you pass arguments to movers when you're overriding them at creation time. The solution now seems to be this beauty:


Which is pretty stupid and redundant. I'll work on that. :waaagh: Anyways, transitions:


Cool? Nope. But soon to have gameplay. Bear with me.

Just added some structural change to make creating elements easier. Instead of having elements define their own Mover, you must specify it at creation time. This makes stuff easier, it's kind of hard to explain. Now to finish up with the GotoMover and also make the triangle fade effect better.

Also! Buttons now have a satisfying 'click' noise, so they are fun to press.

Everything seems to be in order now.. I guess it's time to start working on the actual game..  :facepalm: this is where the troubles seep out of the woodwork and crush your motivation and morale into a pile of sludge on the ground.  :tired:

The only problem right now is stuff like this:


But honestly, that shouldn't be present in the actual game, just on the title screen.. I hope  :addicted:

But yeah. At least the engine is usable, and can be ripped out and used for other games. Forge on!  :handpointR:

Nice project I liked that your little bro is doing the art a lot :) I wish I had a bro like you when I was young :D

Btw his arting is not so bad for an 8 years old person :) nice take :) Hope you both enjoy the development process and waiting to play it when it is finished :)

Thanks much! He's actually quite a lot better on pencil and paper, but hey. Thank you for the encouragement.  :)

Have you tried using a scanner or digital camera then?  I think you can get quite good results with this process:
 1. draw something on paper
 2. scan it, load it into a paint package that supports layers
 3. create another layer on top, reduce the alpha or contrast of the original layer
 4. paint over the picture on the top layer
 5. discard the original layer

I tried that before and it get nice results :) (but I made some modifications afterwards on the image) :) You should try it :) and also may be sometimes you should let him try pixel art :) (not in that project) :) you can get quite good results too :)

Smileys aren't periods.

Anyway... I released the engine on Github today.

https://github.com/SuperDisk/MegaCity-Engine

It's not really meant for serious game building as of yet (it's not done and isn't very well tested) but it might be a nice learning experience for a novice to browse through.

Or maybe I'm the novice  :monoclepop:

LooooL :D

I know but I like them alot :) as it shows how I feel and I like to smile a lot when I see something nice :)

Sorry if that annoyed you :(

Added a couple controls like labels and input boxes. They work alright. Keep in mind though, the Giffer makes really low framerate stuff.. it actually runs at a steady 60 fps.

(http://superdisk.host-ed.me/MegaCity_Junk/SomeControls.gif)

That nice :) keep the good work :)

Thanks!

I'm having some trouble with circular imports, so hopefully that will be resolved soon enough...  :droop:

No one gave me any enlightenment on how to cleanly fix the circular imports, so for now I'm just doing the stupid


and using it rather than doing

from
and just using MiniCityState.

 >:(
Whatever. The project continues  :laughter:

In the news department, I gave the credits screen its own state rather than having FallingButton, because it was just causing more harm than coolness. The image is still a button though.

Didn't work on anything much yesterday but did make a small game:

https://github.com/SuperDisk/DEBATE

It's inspired by Oddball's Argue Mentor, but made in Python.

This doesn't seem related to MegaCity, but it contains some tests of network code that I'm going to incorporate to MegaCity (in a much cleaner way than that, of course)

But yeah. Rules are about the same thing as Oddball's, but you can set your own topic and timeout.

Added creation and deletion of saves.  :)

(Just blank files, because of no gameplay yet  >:()

Tile tests with gameplay. A map full of tiles runs at about 50 FPS, which is below my target 60..  :-X

Probably needs more optimization.

(Should I be merging this all into one post?)

No, separate updates are acceptable.

Found the reason for some of my framerate woes. The collision checking function loops though all objects in the room and does pygame's colliderect method with them. I didn't know this was incredibly superslow until each object does this every frame with 1024 objects.  :laughter:


Time for fixes.

EDIT:
Actually, it's not colliderect at all! It's just looping through all objects for every object is.. really slow. I have no idea how to get around this.

2EDIT:
Actually, it's none of that. My entire system of optimization was just slowing the entire thing down. When I disable the optimizer, my framerate spikes up from the usual 50 to 80. What a waste of work.  :tired:

Added chip (tile) placement and editing. Works at 60 FPS and you can place and remove chips. I'd make a GIF but my host dumped me for too much RAM use.  :-X

Added a (world) Generator class that functions like so:



And that would generate you a flatmap of grass. It also lets me have multiple world generators or let users make their own or something. Yay.

Could you please add some working screens?
Every picture you uploaded till now doesn't work anylonger.  :nono:

The host I had dumped me, and the Gifs that my giffer makes error out on tinypic, imageshack, and some other site that I forgot the name of. I suppose I'll try to find a host.

http://www.postimage.org/

should do.

(http://s14.postimage.org/8iadj8kyp/Untitled.png)

I cropped the image to just the relevant parts. Yay.

I always use imgur.

(http://s11.postimage.org/unt3hdcb7/sdf.png)

Just read about a cool SDL hack and I thought I must try it.
Had to replace Pygame's input things with my own (GetAsyncKeyState rather than Pygame's listening to window events) and it kinda works except the mouse is offsetted by a lot.

Horrible web design. I got the HWND stuff automated so now if I just run the Java app the game loads as well.

(http://s9.postimage.org/6kzcwf7q7/webcti.png)

And on the non WebCity department:

(http://s7.postimage.org/d86oxdb0r/2494288.gif)

Everyone loves animated water, right? (http://gickr.com/results3/anim_f33f3278-dd93-da94-810d-bca3130c6a32.gif)  ???

This game is actually progressing far faster than I thought it would.  :handmetalL:

need actual ingame scrrens, or a follow wont happn

There are some actual ingame screens, but they keep getting taken down by horrible hosts around the world.  >:(

What do you mean by follow?

Now that I've got a 32x32 editable terrain, it's time to expand my horizons into infinity..

Here comes the hard part of splitting it up into chunks and making it not lagtastical.  ???

After delaying a long time on this, I picked it back up for a bit to correct some problems.

Complexity has been added, and there is a lot of cruft in the engine.

Here are a few dandies.

However! Not everything is cruft. I added a new thing called the "Sub-Engine" that lets you specify a Frame, and it will load it as an element in the currently running Frame.

Think Sub-Applications in MMF2.  :) :handthumbsupR:

Fixed the sub-engine so it doesn't load all the resource files each time you create one.  :outraged:

Nextly is for ChipEngine modifications and then perhaps some gameplay!  :o

This is moving at an utterly glacial pace.

Counter incremented to 10% finished! The engine itself is completely laid out, now it's time for the game code to sit ontop of the framework.

Also, the github megacity-engine project is completely out of date, and shouldn't be used as it's full of bugs.

The chipboard (that contains all of the tiles) is an element. Since I don't want it to be updated each frame (re-rendering each and every tile every frame? Yoinks!) I have created the ChipEngine. This too, is an element subclassed from SubEngine (which is in turn subclassed from Engine.)

This lets me selectively update the chipboard and its tiles, as well as have more tight engine control over the tiles.

Even with all of these layers of stuff, game still runs at about 190 fps. I'm going to try to keep it as high as I can, to have room for more stuff. (the actual game will run at 60)

Sounds complex. Isn't really.  ???

(Oh and yes, I fixed a bug pertaining to having multiple InputEngines.)

Sounds like a really sweet idea!  ;D

I'm thinking of rewriting the game in some other language like Pascal or Java, just because of the ridiculous clumsiness I'm encountering with Python. The simplicity and modifiability of it seems very appealing at first, but it becomes a hindrance about now.

For example, I have 1024 chips, each of them an Element. I have an engine that calls their method update() each frame. Nothing really intensive happens in this method. Yet, just the action of calling the method (no, not the stuff in it!) slows the game down by about 200 fps. (I completely commented out the contents of update() and it still slowed it down) This is absolutely ridiculous if I have to avoid structuring my code properly.

Is there anyone else who is having this problem? It's quite hard to just chuck the entirety of my codebase but still.  :handshakeL: :nono: :handshakeR:

Also, thanks for the support, yonder Madk.  :concerned:

Python is balls, man.

For games at least.

I've decided to rewrite in a different language (Pascal), for the challenge! (let's go with that)

Still using SDL though so it is all thoroughly cross-platform.

After working on and off on the Pascal version, I suddenly remembered something wrong with the Python version that's causing it to lag so horribly:

I ACCIDENTALLY CREATED 4X AS MANY TILES AS I NEEDED.

Hahaaha! kill me :-X

1. Are you sure that you're going through your code correctly? I mean, will you need to call update on over a thousand objects, or could you just call it on objects onscreen or near the screen? Could you treat blocks of buildings, for example, as single objects?

2. If you're still going with Python, ensure that you're optimizing your Python flow (http://wiki.python.org/moin/PythonSpeed/PerformanceTips).

3. If you really do need more speed, you could try using a 'speed-up' library like PyPy (http://pypy.org/) or Cython (http://www.cython.org/).

Added chunks, and the ability to save and load them.

It's using the Python pickle module, which is hard to use because it keeps trying to pickle Pygame surfaces and stuff, so I've implemented the __setstate__ and __getstate__ methods on Chips and Chunks so they may be pickled.

Soon, I'll extend it out so that all Elements may be pickled.

Anyways, it's great to be back on track. FPS is (on average) still above 90, so that's good. I've yet to test it on a lame computer, so that might be a shock. :(

Today, boosted performance by adding dirtiness to chips and chunks. Now, I can render a full map of grass and water at 111 fps.

 :)

(https://dl.dropboxusercontent.com/u/33727415/Megacity%20Gifs/Scrollin%27.gif)

More optimizations, and chunk saving/loading.

The world is now infinite infinite infinite Infinite infinite infinite infinite

And still running at 120-esque FPS. I'm quite pleased!  :tearsofjoy:

---

Too bad my summer is completely wasted by huge timesucks though, so I can't be able to goof of on the computer and work on this for lots of time.

Tried to make asynchronous chunk loading, so I made a thing: AsyncGetter.

Use as such.


And this is all in a thread, so it's cool and stuff.

Python threads are not cool and stuff.

Previously chunkloading used to take a long time and would pause the game for half of a second when the map was scrolled onto unloaded chunks.

Found out the problem (it was another stupid "lol lets load 4x what we need" type of thing). Now scrolling is silky smooth.

All is going according to plan.  :lol:

More slow work has happened whenever I feel bored.

Added

• World saving and loading! (this time for real)
• GUI
• Block cursor
• Chat box

The toolbar can be retracted and stuff (and the chatbox moves up and down with it)

(https://dl.dropboxusercontent.com/u/33727415/Megacity%20Gifs/McScreener.bmp)

Time for working on projects is rather scarce, so updates are far between and pretty non-substantive.

Alas.  :concerned:

More lame features:

• Minimap!
• Prettied up the toolbar

(https://dl.dropboxusercontent.com/u/33727415/Megacity%20Gifs/Minimap.png)

The minimap shows my world generator, which currently just picks whether to generate a water chunk or a grass chunk, which is crappy. You can click the minimap to change camera position, which I used to generate my name.

I think now I'll get a better world generator, then actually start making gameplay like I've been telling myself to do for the entire duration of this project.